In this lab, we’re going to talk about vulnerability scanning, execute a couple of sweet scans, and talk about what they dredge up. But first, let’s talk about vulnerabilities.

What is a Vulnerability?

A vulnerability is a weakness or flaw that could potentially permit undesirable actions on your assets (i.e., be exploited). Note the important caveat here: potential. A weakness or flaw requires the existence of a threat (source of harm) that might exploit it. Without a threat, a vulnerability is, in and of itself, inconsequential. And what happens when you have both a vulnerability and a threat? Well, now you have risk, the ultimate metric for assessing vulnerabilities in systems.

The degree of risk is factored based on your special knowledge of the environment (e.g., do compensatory security controls exist, and what impact would successful exploitation have?) and of the threats to its operations (do threats exist, and what is the likelihood of those threats exploiting this vulnerability?). Risk is the metric that ultimately governs which vulnerabilities require attention and in which order. Let’s do an analogy.

Consider you own an unlocked cabinet full of jewelry:

• Vulnerability (input) - A weakness or flaw in an asset. This is the unlocked cabinet.
• Threat (input) - A source of harm that could take advantage of the vulnerability. This might be a burglar after your precious jewelry.
• Risk (output) - The likelihood of a threat exploiting your vulnerability (stealing your jewelry) and the impact this may have (how important is that jewelry, or rather, how costly is the loss of it?). Are you in a high-crime neighborhood? Are they rhinestones or 24-karat gold earrings?

In the above case, the jewelry owner could lock the cabinet to remove the vulnerability, or they could move to a new neighborhood with a lower crime rate. The point is, vulnerability * threat = risk (not really multiplication, just alignment), and it’s the risk that you are ultimately concerned about. Either the threat or the vulnerability must be addressed to affect the risk it poses.

There are many types of vulnerabilities, including system or network misconfigurations, flaws in software or hardware, backdoors, and missing or weak credentials. In this lesson, you will inspect some common vulnerability types in your first analysis of a vulnerability report.

Okay, now you’re ready.

What is Vulnerability Scanning?

Vulnerability Scanning is an automated security assessment technique used to identify weaknesses and flaws in systems that could potentially be exploited by a malicious actor. The targets of a vulnerability scan are assets, which can be defined as any resources an individual or company considers valuable. These could be systems that are critical to business operations, or sensitive data you are obliged to safeguard on behalf of your customer and other stakeholders. Vulnerability scans can be used to assess the effectiveness of an organization’s existing security controls, identify weaknesses and apply corrective measures, or to check adherence to industry standards and regulations.

Vulnerability Scanners & OpenVAS

There are myriad vulnerability scanners available in the cybersecurity space, both free and enterprise. Among the most eminent in the field is Tenable’s Nessus, an enterprise tool with a wide variety of vulnerability tests and a platform for managing discovered vulnerabilities. Similar options include Rapid7’s Nexpose and Qualys, which provide comprehensive vulnerability scanning, as well as a platform for managing vulnerabilities. There are also many scanners that have special focuses, such as Burp Suite, OWASP’s ZAP Proxy, and Nuclei, which focus on web applications; Snyk, which focuses on addressing vulnerabilities in code; and Nikto, which aims to identify misconfigurations in web servers. There is no shortage of vulnerability scanning products out there, but in all cases the goal remains the same: identify vulnerabilities in your assets as a first step in determining the risks posed to an organization. 

In this lab, you will use Greenbone’s OpenVAS (Open Vulnerability Assessment System), an open-source fork of Tenable’s Nessus product. You will access OpenVAS through the Greenbone Security Assistant, a web interface for Greenbone’s Vulnerability Management solution (GVM). You’ll start by reviewing a vulnerability report completed prior to your arrival. This scan was conducted on a server your company hosts in its DMZ (De-Militarized Zone), where it is exposed to the public Internet as customer-facing services. Generally, given its role as an externally available system, it has increased threat exposure, and therefore represents a greater risk than those internal systems tucked safely and completely behind your firewall.

Alright, enough preamble - log in to GSA and check out that report.

1. On the dock at the bottom of the screen, click the Web Browser icon to open a Firefox web browser.
   
2. On the Firefox bookmarks menu, click the Greenbone Security Assistant item to access the Greenbone login page.
   

   

3. Log in to GSA using the following credentials:
   
   Username: admin
   Password: admin
   
   Welcome to the GSA dashboard. This view is customizable, but provides some useful information by default, such as the number of vulnerabilities your scans (Tasks) have revealed. Also included is a graph showing CVEs by creation time – 2017 was clearly a tough year. CVEs (Common Vulnerabilities and Exposures) are publicly disclosed vulnerabilities in software and hardware. When a new software/hardware vulnerability is discovered, it is assigned a CVE Identifier (CVE ID), its severity is determined, and then it is added to a public repository called the NVD (National Vulnerability Database). The NVD and its catalogue of CVEs provides security professionals with common language for referring to unique vulnerabilities and facilitates the exchange of information surrounding them. Not all vulnerabilities will correspond to a CVE, and that should make sense, since something like a default credentials vulnerability is not specific to any software. For any non-CVE vulnerabilities, the scanner will offer its own severity ratings.
   

   

   Note: Severity is generally calculated using a standardized scoring system called the CVSS (Common Vulnerability Scoring System). You won’t be asked any questions based on this, but it’s helpful to know about its existence. OpenVAS has a built-in CVSS interface (Help > CVSS Calculator) that you can use to generate a score based on several criteria, such as the attack method and complexity, and the level of user interaction required. This is particularly useful for quantifying the severity of vulnerabilities discovered during a manual security audit, such as a penetration test, and helps to communicate the comparative severity of each with a client.
   
4. From the top navigation menu, navigate to the Tasks page ( Scans > Tasks).
   

   

5. Click the Sat, Apr 22 link in the Last Report column.
   

   

6. Click the Results tab to view the vulnerabilities discovered by OpenVAS, in order of severity.
   

   

   In addition to the vulnerability name, the solution type is indicated (puzzle piece icon), along with severity, QoD (Quality of Detection – the accuracy and reliability of the detection method), the IP and hostname of the target, the port and protocol used to discover the vulnerability, and the time this vulnerability was identified.
   
   This report contains a few unfortunate discoveries. First, you’ll note the operating system is EOL (End of Life), and so is no longer receiving security updates from the vendor. You’ve heard it before, and you’ll keep hearing it because it’s easy and important: keep your technology up to date!
   
   Among the perennial truths in computer science, right alongside “turn it on and off again will fix anything,” is “keeping your systems up to date will make you invulnerable”. Of course, we’re half kidding – sometimes updates introduce vulnerabilities themselves (as you will discover below), and a sound change management policy is critical – but these are exceptions to the rule. Generally, there is a security advantage to be gained by updating.
   
   Beyond the outdated Operating System, your haul contains some other good examples of other vulnerability types that may cause grief for an organization:
   
   Apache Tomcat AJP RCE Vulnerability (Ghostcat) - A vulnerability in Apache Tomcat, a web application server. This vulnerability allows RCE, or Remote Code Execution, that allows an attacker to execute code on a machine – basically, worst-case scenario.
   
   Riello NetMan 204 Default Credentials (SSH) - Among the most depressing and avoidable vulnerabilities that exist. The high severity is largely due to the ease with which this can be exploited – just log in.
   
   Riello NetMan is a network card that provides access to an Uninterruptible Power Supply (UPS), a backup power source for when the main source is cut. Perhaps a user logs in, disables your UPS, and ensures that when the power goes out, so does your system. Uh oh! Hope you’ve a well-considered disaster recovery plan in place!
   
   vsftpd Compromised Source Packages Backdoor Vulnerability - Backdoor access stored in the official source packages of a popular file transfer software – aka a supply chain vulnerability. Update your software like a responsible digital citizen and find you’ve inadvertently added an express lane for threat actors into your own equipment. Remember how we said updating your systems is crucial? The baddies know this, too, and they love unexceptional cybersecurity programs.
   
   File transfer services generally run on port 21 (the ‘front’ door), but you can see this service is also available on port 6200 (the ‘back’ door).
   
   FTP Unencrypted Cleartext Login - Data is being transmitted in cleartext (see: no encryption)! There’s no excuse for cleartext transmissions in this age. And if this server is expected to handle sensitive customer data, such as personally identifying information (PII), the degree of risk skyrockets.
   
   Anonymous FTP Login Reporting - A warning that you are allowing anonymous access (no user-specific accounts required) to your file server. This requires additional context, since this may be by design, such as for a repository of software made available to the general public for download.
   
   ICMP Timestamp Reply Information Disclosure - A low severity vulnerability that reports timestamp information is being disclosed via the ICMP (ping) protocol. If you were using some weak time-based random number generators, perhaps to generate material for use in establishing an encrypted connection, then theoretically this vulnerability might allow exploitation of those mechanisms. That said, this is easy to solve – disable timestamps in ICMP, or just block ICMP traffic altogether (a common for public-facing systems).
   
   Additional information about the vulnerability can be obtained by clicking on its name in the first column.
   
7. Click the Apache Ghostcat vulnerability to view additional information.
   
   Notice the scary headline in the Summary section: “prone to RCE” (Remote Code Execution. Scary indeed, but the details are essential.
   

   

8. Scroll down to the References header at the bottom of the page to view the associated CVE, then click the corresponding link to open the details of this CVE.
   

   

   The CVE page may take a few seconds to load.
   
   This is the official description of the vulnerability as it exists in the NVD. You need not absorb all the details, but there are some important qualifying bits in there, specifically:
   
   “if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means), then this, along with the ability to process a file as a JSP, made remote code execution possible.”
   
   Actually, Ghostcat is technically a local file inclusion (LFI) vulnerability, which allows opening files on the local server in the context of the application. As noted in the passage above, RCE is only possible if the attacker is also able to upload their own malicious files to the server (the inclusion of which can provide them RCE). This would be an important criterion to validate before determining the risk this vulnerability poses. That said, you’ve already seen several vulnerabilities related to the file transfer (FTP) software installed on this machine, so it’s very possible that you satisfy that criterion…. But the point is, it’s important to consider the possible interactions available and overlap across your complete vulnerability profile, rather than assessing each in isolation.
   
   Let’s check out one more before closing out this lesson.
   
9. Navigate back to the Tasks page ( Scans > Tasks), then re-open the Sat, Apr 22 report and click the Results tab.
   
10. Click the Anonymous FTP Login Reporting vulnerability to view additional details.
    

    

    At the bottom, under References, you’ll see this vulnerability is tied to a CVE. However, if you look at the Insight provided, you’ll see the CVE is assigned a severity of 0.0, because it is considered a misconfiguration issue rather than a software flaw. While the CVE itself has a null severity ranking, OpenVAS has called this medium severity to draw attention to the potential impact (depending on your threats, remember?), avoiding possible oversight should this be a misconfiguration. If anonymous logins are not intentional, and provide access to sensitive data on the fileserver, then brace for impact.
    
    Alright, that’s plenty to chew on. We’ve talked about vulnerabilities, vulnerability scanning, and analyzed a vulnerability report. Now, let’s test our ability to write a lab your understanding.
    
    Good luck, and we’ll catch you in the Guided Exercise!